[TrimmableTypeMap] Root manifest-referenced types as unconditional#11016
Closed
simonrozsival wants to merge 2 commits intodev/simonrozsival/trimmable-typemap-build-pipelinefrom
Closed
Conversation
simonrozsival
commented
Mar 25, 2026
| // Multiple managed types can map to the same Java name (aliases). | ||
| var peersByDotName = new Dictionary<string, List<JavaPeerInfo>> (StringComparer.Ordinal); | ||
| foreach (var peer in allPeers) { | ||
| var dotName = peer.JavaName.Replace ('/', '.'); |
Member
Author
There was a problem hiding this comment.
I believe this is not enough - nested types would have $ that also needs to be replaced with . to form valid Java name. Is this the same problem we had elsewhere? Should this be a helper method? Or is there an existing helper method we could use?
simonrozsival
commented
Mar 25, 2026
Comment on lines
+281
to
+289
| var manifestPath = Path.Combine (manifestDir, "AndroidManifest.xml"); | ||
| File.WriteAllText (manifestPath, """ | ||
| <?xml version="1.0" encoding="utf-8"?> | ||
| <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.test"> | ||
| <application> | ||
| <activity android:name="android.app.Activity" /> | ||
| </application> | ||
| </manifest> | ||
| """); |
Member
Author
There was a problem hiding this comment.
Can we do this without writing to a file? Can we somehow change this to use memory stream instead? I believe we could just change GenerateTrimmableTypeMap so it expects the ManifestTemplate to be the memory stream (+ of course use memory stream pooling!)
simonrozsival
force-pushed
the
dev/simonrozsival/trimmable-typemap-build-pipeline
branch
from
6f42b4d to
384a5a8
Compare
When users hand-edit AndroidManifest.xml with component entries that have no corresponding C# attribute (e.g. [Activity]), the referenced types may be trimmed by the linker, causing runtime crashes when Android tries to launch them. This change adds RootManifestReferencedTypes() which parses the manifest template before typemap assembly generation, finds matching peers by their Java name, and marks them as unconditional so the linker preserves them. A warning is logged for manifest-referenced types not found in any scanned assembly (likely framework types). Changes: - JavaPeerInfo.IsUnconditional: changed from init to set - GenerateTrimmableTypeMap: added RootManifestReferencedTypes method - Added two tests for rooting and warning behavior Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Parse the user's AndroidManifest.xml template to find hand-edited component entries (activity, service, receiver, provider) and mark matching Java peers as unconditional so they survive trimming. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
simonrozsival
force-pushed
the
dev/simonrozsival/trimmable-typemap-post-manifest-rooting
branch
from
1a0330a to
6831cef
Compare
Member
Author
simonrozsival
added a commit
that referenced
this pull request
Mar 27, 2026
Parse the user's AndroidManifest.xml template for activity, service, receiver, and provider elements with android:name attributes. Mark matching scanned Java peer types as IsUnconditional = true so the ILLink TypeMap step preserves them even if no managed code references them directly. Changes: - JavaPeerInfo.IsUnconditional: init → set (must be mutated after scanning) - TrimmableTypeMapGenerator: add warn callback, RootManifestReferencedTypes() called between scanning and typemap generation - GenerateTrimmableTypeMap task: pass Log.LogWarning as warn callback - 4 new xUnit tests covering rooting, unresolved warnings, already-unconditional skip, and empty manifest Replaces #11016 (closed — depended on old PR shape with TaskLoggingHelper). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #10807
Depends on #10980
Summary
Ensures types declared only in hand-edited
AndroidManifest.xml(no C# component attribute) are marked as unconditional and survive trimming.Problem
A user can hand-edit their manifest with
<activity android:name="com.example.MyLegacyActivity" />where the type has[Register]but no[Activity]attribute. Without this fix, the scanner treats it as a conditional peer (3-argTypeMapAttribute) and the linker may trim it → runtime crash.Changes
JavaPeerInfo.cs: ChangedIsUnconditionalfrominittosetso it can be mutated after scanningGenerateTrimmableTypeMap.cs: AddedRootManifestReferencedTypes()that parsesManifestTemplateXML, extractsandroid:namevalues, and marks matching peers as unconditional